Random early drop based processing circuit and method for triggering random early drop based operation according to at least trigger event generated based on software programmable schedule

ABSTRACT

A random early drop (RED) based processing circuit includes a scheduler, an RED-based decision logic and a controller. The scheduler generates a trigger event according to an RED-based operation schedule. The scheduler is coupled to a software interface, and the RED-based operation schedule in the scheduler is programmed via the software interface. The RED-based decision logic performs at least a first RED-based operation to generate a first RED decision accordingly. The controller receives at least the trigger event, and triggers the RED-based decision logic to perform the first RED-based operation according to at least the trigger event.

CROSS REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. provisional application No.61/815,922, filed on Apr. 25, 2013 and incorporated herein by reference.

BACKGROUND

The disclosed embodiments of the present invention relate to congestionavoidance in a network environment, and more particularly, to a randomearly drop (RED) based processing circuit and method for triggering anRED-based operation (e.g., a weighted random early drop (WRED)operation) according to at least a trigger event (such as a time-basedtrigger event) generated based on a software programmable schedule.

In general, a network device (e.g., a switch) has a packet buffer forbuffering packets transmitted from one or more packet sources. Thepacket buffer may be a dynamic random access memory (DRAM) with alimited memory size. If an overall line rate (data rate) of the ingresstraffic is higher than an overall line rate (data rate) of the egresstraffic, the number of packets arriving at the packet buffer is largerthan the number of packets released from the packet buffer. In a worstcase, the network device would suffer from packet congestion in thepacket buffer.

To detect and avoid congestion, a congestion avoidance technique may beemployed. For example, a cruder packet drop mechanism called tail dropmay be used. However, the tail drop treats traffic of all ports/queuesequally and does not differentiate between classes of services. When thepacket buffer is full and the tail drop is in effect, newly arrivingpackets of all ports/queues are dropped until the congestion iseliminated and the packet buffer is no longer full. In other words, thepacket buffer is allowed to fill to its maximum size, and then any newpackets are simply discarded. As a result, when the packet buffer isalready full and there is a sudden burst of packet traffic from one ormore hosts, the network device would lose all incoming packetssimultaneously, thus resulting in poor packet forwarding performance.

An improved congestion avoidance technique may be used to reduce thechances of tail drop due to packet buffer full. For example, a weightedrandom early drop (WRED) mechanism may be used to selectively droppackets when the output interface begins to show signs of congestion.However, the WRED operation is a hardware costly operation. For example,multiple hardware-based WRED circuits are needed to make WRED decisionsfor multiple ports/queues, respectively.

SUMMARY

In accordance with exemplary embodiments of the present invention, arandom early drop (RED) based processing circuit and method fortriggering an RED-based operation (e.g., a weighted random early drop(WRED) operation) according to at least a trigger event generated basedon a software programmable schedule are proposed to solve theabove-mentioned problem.

According to a first aspect of the present invention, an exemplaryrandom early drop (RED) based processing circuit, such as a weightedrandom early drop (WRED) processing circuit, is disclosed. The RED basedprocessing circuit includes a scheduler, a RED-based decision logic anda controller. The scheduler is configured to generate a trigger eventaccording to a RED-based operation schedule. The scheduler is coupled toa software interface, and the RED-based operation schedule in thescheduler is programmed via the software interface. The RED-baseddecision logic is configured to perform at least a first RED-basedoperation to generate a first WRED decision accordingly. The controlleris configured to receive at least the trigger event, and trigger theRED-based decision logic to perform the first RED-based operationaccording to at least the trigger event.

According to a second aspect of the present invention, an exemplaryrandom early drop (RED) based processing method, such as a weightedrandom early drop (WRED) processing method, is disclosed. The exemplaryRED based processing method includes: programming an RED-based operationschedule via a software manner; generating a trigger event according tothe RED-based operation schedule; and referring to at least the triggerevent for triggering a RED-based decision logic to perform at least afirst RED-based operation to generate a first RED decision accordingly.

These and other objectives of the present invention will no doubt becomeobvious to those of ordinary skill in the art after reading thefollowing detailed description of the preferred embodiment that isillustrated in the various figures and drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram illustrating a WRED processing circuitaccording to a first embodiment of the present invention.

FIG. 2 is a diagram illustrating a software programmable memoryaccording to an embodiment of the present invention.

FIG. 3 is a diagram illustrating an alternative design of the WREDoperation schedule stored in the software programmable memory shown inFIG. 2.

FIG. 4 is a block diagram illustrating a WRED processing circuitaccording to a second embodiment of the present invention.

FIG. 5 is a block diagram illustrating a WRED processing circuitaccording to a third embodiment of the present invention.

DETAILED DESCRIPTION

Certain terms are used throughout the description and following claimsto refer to particular components. As one skilled in the art willappreciate, manufacturers may refer to a component by different names.This document does not intend to distinguish between components thatdiffer in name but not function. In the following description and in theclaims, the terms “include” and “comprise” are used in an open-endedfashion, and thus should be interpreted to mean “include, but notlimited to . . . ”. Also, the term “couple” is intended to mean eitheran indirect or direct electrical connection. Accordingly, if one deviceis coupled to another device, that connection may be through a directelectrical connection, or through an indirect electrical connection viaother devices and connections.

The concept of the present invention is using shared weighted randomearly drop (WRED) hardware to serve multiple WRED calculation requestsfor multiple monitored WRED targets (e.g., network ports of the networkdevice or queues of network ports of the network device). In this way, alow-cost WRED mechanism can be realized. Besides, the WRED operationsare scheduled based on a software programmable schedule. The user isallowed to define the sequence of WRED operations according to anytrigger condition and/or application requirement, thus improving theflexibility of WRED operation scheduling. For example, the WREDoperations are scheduled based on predetermined time intervals definedby the software programmable schedule, rather than unpredictable packetarrivals. Hence, when the line rate is high, the inaccuracy introducedby a typical WRED update interval between two consecutive packetarrivals can be avoided. Therefore, the present invention provides animproved WRED design which can maintain the WRED accuracy while reducingthe hardware cost. Moreover, the WRED operation on unlikely congestedport/queue may be skipped for power saving.

For clarity and simplicity, the following uses a WRED processing circuitas an example to illustrate technical features of the present invention.However, it should be noted that the same concept may be applied to anyrandom early drop (RED), also known as random early detection or randomearly discard, based processing circuit. In other words, the terms“WRED” and “RED-based” may be interchangeable without departing from thespirit of the present invention. These alternative designs all fallwithin the scope of the present invention.

FIG. 1 is a block diagram illustrating a WRED processing circuitaccording to a first embodiment of the present invention. The WREDprocessing circuit 100 may be employed in a network device such as aswitch. In this embodiment, the WRED processing circuit 100 includes ascheduler 102, a controller 104 and a WRED decision logic 106. Thescheduler 102 is configured to generate a time-based trigger event TRG_Tto the controller 104 according to a WRED operation schedule SCH. In oneexemplary design, the scheduler 102 may be simply implemented using amemory device. Please refer to FIG. 2, which is a diagram illustrating asoftware programmable memory according to an embodiment of the presentinvention. The software programmable memory 200 has a WRED operationschedule 201 stored therein, and may be used as the scheduler 102 shownin FIG. 1. The WRED operation schedule 201 includes a plurality ofentries 202, each storing an index value of a monitored WRED target.Taking the schedule design in FIG. 2 for example, each monitored WREDtarget is a network port of the network device. Therefore, an indexvalue in a schedule entry may simply record a port number. Specifically,one network port may have a plurality of queues allocated in the packetbuffer. Different queues of the same network port are associated with aplurality of difference services, such that packets of the same serviceare stored in the same queue. Hence, when a WRED operation is triggeredfor a selected network port in one time interval (time slot), the WREDdecision logic 106 may generate a WRED decision which includes WREDcalculation results for all queues in the selected network port.However, this is for illustrative purposes only, and is not meant to bea limitation of the present invention. For another example, themonitored WRED target may be one queue of a network port of the networkdevice. FIG. 3 is a diagram illustrating an alternative design of theWRED operation schedule stored in the software programmable memory 200shown in FIG. 2. In this embodiment, the WRED operation schedule 301includes a plurality of entries 202, each storing an index value of aqueue of a network port. Therefore, an index value in a schedule entrymay simply record a port number and a queue number. Hence, when a WREDoperation is triggered for a selected queue in one time interval, theWRED decision logic 106 may generate a WRED decision which includes oneWRED calculation result for the selected queue only. This also fallswithin the scope of the present invention.

Assume that each monitored WRED target is one network port, asillustrated in FIG. 2. The SW programmable memory 200 (i.e., scheduler)cyclically reads and outputs index values in the entries 202 one by oneto thereby set and generate the time-based trigger event once in each ofa plurality of time intervals (e.g., T1, T2, . . . T14 in FIG. 2).Hence, based on setting of the WRED operation schedule 201, the WREDdecision logic 106 generates one WRED decision during each of the timeintervals T1-T14 in response to a corresponding time-based trigger eventwhich specifies the network port to which the WRED calculation isapplied. As the WRED mechanism is employed by the network device forcongestion avoidance, the index values should be properly set to makehigher-priority ports have more WRED operations in one schedule cycle(e.g., T1-T14) and lower-priority ports have fewer WRED operations inthe same schedule cycle (e.g., T1-T14).

It is possible that at least one network port/queue of the networkdevice is less frequently used for dealing with packets. For example,the packet traffic an e-mail service is generally low. Hence, the WREDoperation of such unlikely congested port/queue may be skipped for powersaving. In other words, no matter whether a packet is received or not, aWRED operation would never be triggered for an unlikely congestedport/queue. In one exemplary design, an index value of at least onespecific network port or at least one specific queue may be excludedfrom the WRED operation schedule. In this way, no WRED operation wouldbe scheduled for the at least one specific network port/queue. The powerconsumption of the proposed WRED processing circuit is reducedaccordingly.

As shown in FIG. 1, the scheduler 102 is coupled to a software interface101. Hence, the WRED processing circuit 100 allows the WRED operationschedule SCH in the scheduler 102 to be programmed via the softwareinterface 101. The user of the network device may manually configure theWRED operation schedule SCH according to the actual network port/queuecondition of the network device. For example, network ports Port 0 andPort 1 are high line rate ports, and thus are more important and shouldhave higher priority. As shown in FIG. 2, the WRED operation schedule201 is set to schedule more WRED operations to the network ports Port 0and Port 1. In other words, the occurrence frequency of WRED operationsfor each of the high-priority network ports Port 0 and Port 1 would behigher than that of other low-priority network ports (e.g., Port 2-Port11). Since the WRED operation schedule 201 is not fixed in the schedule102, the WRED operation schedule 201 can be dynamically adjusted basedon the actual operational condition of the network device, thusachieving better congestion avoidance performance due to flexibility ofWRED operation scheduling.

The controller 104 in FIG. 1 receives each time-based trigger eventTRG_T scheduled and outputted from the scheduler 102, and then triggersthe WRED decision logic 106 to perform a corresponding WRED operation inresponse to the current time-based trigger event. In other words, whentriggered by the controller 104, the WRED decision logic 106 performs aWRED operation for a monitored WRED target (e.g., one network port orone queue) to generate a WRED decision (e.g., multiple WRED calculationresults for all queues of a network port, or a single WRED calculationresult for one queue of a network queue) accordingly. The WRED decisiontells whether a packet source should decrease its transmission rate tomitigate/eliminate the congestion. By dropping some packets early ratherthan waiting until the queue is full, WRED avoids dropping a largenumber of packets at once. Thus, WRED allows the transmission line to beused fully at all times.

In a case where the monitored WRED target is one queue of a networkport, the WRED operation may include calculating a packet dropprobability Probability_(drop) based on a minimum thresholdThreshold_(min), a maximum threshold Threshold_(max), a maximum packetdrop probability Probability_(max), and an average queue lengthQueue_(avg), and making the WRED decision based on the calculated packetdrop probability Probability_(drop). The packet drop probabilitycalculation may be represented using following equation.

$\begin{matrix}{{probability}_{drop} = {\frac{{Queue}_{avg} - {Threshold}_{\min}}{{Threshold}_{\max} - {Threshold}_{\min}} \cdot {probability}_{\max}}} & (1)\end{matrix}$

The average queue length Queue_(avg) is a weighted average (movingaverage) derived from a previous average queue length and a currentqueue length. When the controller 104 receives a trigger event (e.g.,the time-based trigger event in this embodiment), the controller 104requests parameters, including Queue_(avg), Threshold_(min),Threshold_(max) and Probability_(max), from a circuit element (notshown), and then provides the received parameters needed for WREDcalculation to the WRED decision logic 106. As can be seen from FIG. 2,a WRED operation for one monitored WRED target (e.g., a network port ora queue) is regularly performed by the WRED decision logic 106 accordingto the WRED operation schedule 201. Thus, the inaccuracy introduced by atypical WRED update interval between two consecutive arriving packetscan be avoided.

The WRED processing circuit 100 shown in FIG. 1 operates under atime-based trigger mode such that the WRED decision logic 106 can beimplemented using shared computation hardware for performing WREDoperation for a monitored WRED target in one time interval. Since theWRED decision logic 106 operates in a time-division manner, it does notneed to have multiple sets of computation hardware dedicated toperforming respective WRED operations for multiple monitored WREDtargets. Therefore, the hardware cost can be effectively reduced.

It should be noted that the WRED processing circuit 100 shown in FIG. 1is for illustrative purposes only. Any WRED processing circuit using theproposed software programmable WRED operation scheduling to regularly orperiodically generate one time-based trigger event to request WREDoperation for a designated WRED target (e.g., a network port or a queueof one network port) falls within the scope of the present invention.For example, the present invention further proposes a hybrid-mode WREDprocessing circuit which reacts to at least one of a received time-basedtrigger event and a received packet-based trigger event.

Please refer to FIG. 4, which is a block diagram illustrating a WREDprocessing circuit according to a second embodiment of the presentinvention. The WRED processing circuit 400 is a hybrid-mode WREDprocessing circuit. The major difference between WRED processingcircuits 100 and 400 is the controller 404 that is further configured toreceive a packet-based trigger event TRG_P. The packet-based triggerevent TRG_P may be a packet arrival event or a packet release event. Inacase where the packet-based trigger event TRG_P is a packet arrivalevent, the packet-based trigger event TRG_P is generated each time apacket arrives at a monitored WRED target (e.g., a network port or aqueue of one network port). In another case where the packet-basedtrigger event TRG_P is a packet release event, the packet-based triggerevent TRG_P is generated each time a packet is released from a monitoredWRED target (e.g., a network port or a queue of one network port). Asmentioned above, the scheduler 102 outputs one time-based trigger eventTRG_T in one scheduled time interval (time slot). When there is nopacket-based trigger event TRG_P happening in the current time interval,the WRED processing circuit 400 operates like the WRED processingcircuit 100. That is, the controller 404 triggers the WRED decisionlogic 106 to perform the WRED operation for a designated WRED targetaccording to the WRED target information (e.g., port number or queuenumber) specified in the time-based trigger event TRG_T. However, whenthe time-based trigger event TRG_T and the packet-based trigger eventTRG_P are simultaneously received by the controller 404, the controller404 would serve the packet-based trigger event TRG_P first to triggerthe WRED decision logic 106. By way of example, the controller 404 maydirectly ignore the time-based trigger event TRG_T, and trigger the WREDdecision logic 106 to perform the WRED operation for a designated WREDtarget according to WRED target information (e.g., packet destinationinformation) specified in the packet-based trigger event TRG_P.

FIG. 5 is a block diagram illustrating a WRED processing circuitaccording to a third embodiment of the present invention. The WREDprocessing circuit 500 is another hybrid-mode WRED processing circuit.The major difference between WRED processing circuits 100 and 400 is thecontroller 504 and the WRED decision logic 506. In this embodiment, theWRED decision logic 506 has two WRED operation units that can operateindependently. That is, the WRED operation unit 512 is configured toperform one WRED operation to generate one WRED decision; and the WREDoperation unit 514 is configured to perform another WRED operation togenerate another WRED decision. Regarding the controller 504, it isfurther configured to receive a packet-based trigger event TRG_P, wherethe packet-based trigger event TRG_P may be a packet arrival event or apacket release event. Since two WRED operation units 512, 514 canoperate independently, the controller 504 triggers the WRED operationunit 512 according to the time-based trigger event TRG_T, and triggersthe WRED operation unit 514 according to the packet-based trigger eventTRG_P. Specifically, the WRED operation unit 512 operates like the WREDdecision logic 106 shown in FIG. 1, and have the same aforementionedbenefits/advantages possessed by the WRED decision logic 106.

As mentioned above, the scheduler 102 outputs one time-based triggerevent TRG_T in one scheduled time interval (time slot). When thetime-based trigger event TRG_T and the packet-based trigger event TRG_Pfor different monitored WRED targets are simultaneously received by thecontroller 504, the controller 504 serves both of the time-based triggerevent TRG_T and the packet-based trigger event TRG_P by triggering WREDoperation units 512 and 514 respectively. Therefore, during the sametime interval, the WRED operation unit 512 makes a WRED decision for onemonitored WRED target (e.g., Port 0), and the other WRED operation unit514 makes a WRED decision for a different monitored WRED target (e.g.,Port 1). However, when the time-based trigger event TRG_T and thepacket-based trigger event TRG_P for the same monitored WRED target(e.g., Port 0) are simultaneously received by the controller 504, aconflict would occur if the WRED operation units 512, 514 both try tomake WRED decisions for the same monitored WRED target. To avoid theconflict issue, the controller 504 is configured to ignore thepacket-based trigger event TRG_P without triggering the WRED operationunit 514. In other words, the controller 504 would serve the time-basedtrigger event TRG_T to trigger the WRED operation unit 512 only.

Those skilled in the art will readily observe that numerousmodifications and alterations of the device and method may be made whileretaining the teachings of the invention. Accordingly, the abovedisclosure should be construed as limited only by the metes and boundsof the appended claims.

What is claimed is:
 1. A random early drop (RED) based processingcircuit, comprising: a scheduler, configured to generate a trigger eventaccording to an RED-based operation schedule, wherein the scheduler iscoupled to a software interface (101), and the RED-based operationschedule in the scheduler is programmed via the software interface; anRED-based decision logic, configured to perform at least a firstRED-based operation to generate a first RED decision accordingly; and acontroller, configured to receive at least the trigger event, andtrigger the RED-based decision logic to perform the first RED-basedoperation according to at least the trigger event.
 2. The RED basedprocessing circuit of claim 1, wherein the RED-based operation scheduleis a weighted random early drop (WRED) operation schedule, the RED-baseddecision logic is a WRED decision logic, and the first RED-basedoperation is a WRED operation.
 3. The RED based processing circuit ofclaim 1, wherein the trigger event is a time-based trigger event.
 4. TheRED based processing circuit of claim. 3, wherein the RED-basedoperation schedule includes a plurality of entries, each storing anindex value of a monitored target; and the scheduler cyclically readsindex values in the entries one by one to set and generate thetime-based trigger event once in each of a plurality of time intervals.5. The RED based processing circuit of claim 4, wherein the monitoredtarget is a network port of a network device or a queue of the networkport of the network device.
 6. The RED based processing circuit of claim5, wherein an index value of at least one network port or at least onequeue is excluded from the RED-based operation schedule.
 7. The REDbased processing circuit of claim 3, wherein the controller is furtherconfigured to receive a packet-based trigger event; and the controllertriggers the RED-based decision logic according to at least one of thetime-based trigger event and the packet-based trigger event.
 8. The REDbased processing circuit of claim 7, wherein the packet-based triggerevent is a packet arrival event.
 9. The RED based processing circuit ofclaim 7, wherein the packet-based trigger event is a packet releaseevent.
 10. The RED based processing circuit of claim 7, wherein when thetime-based trigger event and the packet-based trigger event aresimultaneously received by the controller, the controller serves thepacket-based trigger event first to trigger the RED-based decisionlogic.
 11. The RED based processing circuit of claim 3, wherein theRED-based decision logic comprises: a first RED-based operation unit,configured to perform the first RED-based operation to generate thefirst RED decision; and a second RED-based operation unit, configured toperform a second RED-based operation to generate a second RED decision;wherein the controller is further configured to receive a packet-basedtrigger event; the controller triggers the first RED-based operationunit according to the time-based trigger event, and triggers the secondRED-based operation unit according to the packet-based trigger event.12. The RED based processing circuit of claim 11, wherein when thetime-based trigger event and the packet-based trigger event for a samemonitored target are simultaneously received by the controller, thecontroller serves the time-based trigger event to trigger the firstRED-based operation unit only.
 13. A random early drop (RED) basedprocessing method, comprising: programming an RED-based operationschedule via a software manner; generating a trigger event according tothe RED-based operation schedule; and referring to at least the triggerevent for triggering an RED-based decision logic to perform at least afirst RED-based operation to generate a first RED decision accordingly.14. The RED based processing method of claim 13, wherein the RED-basedoperation schedule is a weighted random early drop (WRED) operationschedule, the RED-based decision logic is a WRED decision logic, and thefirst RED-based operation is a WRED operation.
 15. The RED basedprocessing method of claim 13, wherein the trigger event is a time-basedtrigger event.
 16. The RED based processing method of claim 15, whereinthe RED-based operation schedule includes a plurality of entries, eachstoring an index value of a monitored target; and the step of generatingthe time-based trigger event comprises: cyclically reading index valuesin the entries one by one to set and generate the time-based triggerevent once in each of a plurality of time intervals.
 17. The RED basedprocessing method of claim 16, wherein the monitored target is a networkport of a network device or a queue of the network port of the networkdevice.
 18. The RED based processing method of claim 17, wherein anindex value of at least one network port or at least one queue isexcluded from the RED-based operation schedule.
 19. The RED basedprocessing method of claim 15, further comprising: receiving apacket-based trigger event; wherein the step of triggering the RED-baseddecision logic comprises: triggering the RED-based decision logicaccording to at least one of the time-based trigger event and thepacket-based trigger event.
 20. The RED based processing method of claim19, wherein the packet-based trigger event is a packet arrival event.21. The RED based processing method of claim 19, wherein thepacket-based trigger event is a packet release event.
 22. The RED basedprocessing method of claim 19, wherein when the time-based trigger eventand the packet-based trigger event are simultaneously received, thepacket-based trigger event is first served to trigger the RED-baseddecision logic.
 23. The RED based processing method of claim 15, furthercomprising: receiving a packet-based trigger event; wherein theRED-based decision logic comprises: a first RED-based operation unit,configured to perform the first RED-based operation to generate thefirst RED decision; and a second RED-based operation unit, configured toperform a second RED-based operation to generate a second RED decision;wherein the step of triggering the RED-based decision logic comprises:triggering the first RED-based operation unit according to thetime-based trigger event; and triggering the second RED-based operationunit according to the packet-based trigger event.
 24. The RED basedprocessing method of claim 23, wherein when the time-based trigger eventand the packet-based trigger event for a same monitored target aresimultaneously received, only the time-based trigger event is served totrigger the first RED-based operation unit.